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(54) System zur Verification von Software-Anwendungsmodellen in Ketten von 
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(57) Die Erfindung bezieht sich auf ein System zur 
Verifikation von Sottware-Anwendungsmodellen in Ket- 
ten von Software-Entwurfswerkzeugen. Die Anwen- 
dungsmodelle sind Instanzen eines Metamodelis sind, 
welches die Struktur von Modellen einer Software-An- 
wendung sowie Schnittsteilen zu diesen Modellen be- 
schreibt, und aul dem alle Werkzeuge der Werkzeug- 
kette aufbauen. Das System beinhaltet ein Verifier-Fra- 
mework einschlieBlich einem Verifier-Manager sowie 
mehrere Verifizierer, wobei ein Verifizierer jeweils als ei- 
ne Gruppe von formulierten Bedingungen und Regeln 
fur jeweils eines der Modelle der Software-Anwendung 
gebildetwird, und mittelsdes Verifier-Managers Verifier- 
Gruppen im Verifier- Framework zur Prufung festgeleg- 
ter Modellelementezusammengestelitwerden. Das Sy- 
stem ist dafur eingerichtet, die Verifizierung von Soft- 
waremodellen bezuglich Vertraglichkeit mit den formu- 
lierten Bedingungen und Regeln mittels eines Uberpru- 
fungslaufs unter Verwendung des Metamodelis vorzu- 
nehmen, wobei sich als Ergebnis die festgestellten Be- 
dingungs- oder Regelverletzungen ergeben. 
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Beschreibung 

[0001 ] Die Erfindung bezieht sich auf eln System zur Verifikation von Software-Anwendungsmodellen in Ketten von 
Software-Entwurfswerkzeugen. 

[0002] Bei der Erstellung von IT-Systemen kommen vermehrt Werkzeuge und wiederverwendbare Softwarebaustei- 
ne - auch Komponenten genannt - zum Einsatz, welche die Entwickler in ihrer Arbeit unterstutzen. Dabei gibt es eine 
nahezu unuberschaubare Menge an Werkzeug- und Komponententypen. Beispiele sind einfache Texteditoren zum 
Bearbeiten von Quellcode, Werkzeuge zur Ertassung von Anforderungen an ein Software-System, Design-Werkzeuge, 
Ubersetzer, Generatoren, Transaktionsmanagement-Systeme, Datenbanken Oder ganze Ablaufumgebungen fur An- 
wendungen, sog. Application Server. Je nach Ausgestaltung eines Software-Entwicklungsprozesses werden viele sol- 
cher Werkzeuge zusammengefa&t und miteinander integriert, wobei sich zumeist def iniert durch den ProzeG eine Ware 
Reihenfolge erkennen laBt, in der die Werkzeuge in der Entwicklung zum Einsatz kommen. In solchen Fallen kann 
von einer Werkzeugkette gesprochen werden. Am Ende eines vollstandigen und korrekten Durchlaufs durch eine sol- 
che Kette steht ublicherweise ein lauffahiges Software-System. 

[0003] Es gibt im Bereich des computergestutzten Softwareentwurfs und der-entwicklung, auch CASE - Computer 
Aided Software Engineering genannt, eine Vielzahl von machtigen Werkzeugen, teils als kommerzielle Produkte kauf- 
lich, teils als kostenlo'se Software beispielsweise aus dem Internet beziehbar. Interessant ist hier vor allem die Be- 
trachtung bereits verfugbarer Werkzeugteffen, die als solche ausgeprSgt slnd. 

[0004] Hier sind zum einen die "klassischen" integrierten Entwicklungsumgebungen, sog. IDE- Integrated Develop- 
ment Environment zu nennen, die sich in der Vergangenheit zumeist darauf beschrankten, eine nahtlose Integration 
zwischen Editor, Konstruktionshiffen fur graphische Benutzungsschnittstellen, Ubersetzer, Debugger und oftmals ex- 
ternen Werkezeugen wie z.B. Version ierungs- und Konfigu ratio nsverwaltungswerkzeu gen herzusfellen; Nennenswerte 
Produkte in diesem Bereich sind SNiFF+ von der Firma TakeFive, jetzt WindRiver, JBuilder von der Firma Borland / 
Inprise, Symantec Cafe von der Firma Symantec Oder Visual C++/J++ von der Firma Microsoft. 
[0005] Zum anderen gibt es im Bereich der engeren Fassung des Begrlff es CASE einige Werkzeugketten, die den 
Anwender von den fruhen Phasen des Entwurfs, also z.B. der Analyse und der Erfassung der Anforderungen begleiten 
bis hin zur Erzeugung des lauffahigen Software-Systems. Beispiele hierfur sind die Werkzeuge der Firma Rational, 
die Produkte der Firma Together oder das Produkt ArcStylervon der Firma Interactive Objects Software GmbH. 
[0006] Auch im akademischen Bereich gab es Forschung zum Thema der Integration von Werkzeugen zum Soft- 
wareentwurf. Hier ist besonders zu erwahnen das Projekt STOA/E(siehe Eduardo Casais, Claus Lewerentz, STONE 
project monograph: Issues in Tool Integration, Forschingszentrum Informatik, Karlsruhe, ISSN 0944-3037), das zu 
Teilen am Forschungszentrum Informatik an der Universitat Karlsruhe TU durchgefuhrt wurde. 
[0007] Beim Durchlaufen einer Werkzeugkette gibt es zahlreiche potentielle Fehlerquellen. Daher bieten die meisten 
Werkzeuge eine mehr oder weniger gut ausgepragte Unterstutzung in der Auffindung und Behebung von Fehlem an. 
Ein eingangiges Beispiel fur die Fehlererkennung in solchen Werkzeugketten sind die syntaxbewuBten Quellcodeedi- 
toren. Dabei findet in der Regel eine farbliche Hervorhebung syntaktischer Elemente im Quellcode durch den Editor 
statt, so daG der Entwickler moglichst rasch und leicht Konstrukte im Code identifizieren kann, die von nachgeschalteten 
Werkzeugen, z.B. dem Ubersetzer, fur unzulassig erkannt wurden. So erspart dieses Vorgehen in manchen Fallen 
einen unnotigen Ubersetzerdurchlauf, der nur die bereits fruher erkennbaren Fehler aufgedeckt hatte, urn nach an- 
schlieBender Uberarbeltung der Eingaben wlederholt ausgefuhrt zu werden. 

[0008] Dabei wird jedoch explizit im vorgeschalteten Werkzeug, im Beispiel dem Editor, Wissen uber Randbedin- 
gungen eines nachgeschalteten Werkzeugs integriert. So enthalt beispielsweise ein im Werkzeug JBuilder von der 
Firma Borland/ Inprise integrierter Editor zwar die Regeln fur die Syntax der Programmiersprache Java, nicht jedoch 
die der Sprache Fortran. Wurden also mit diesem Editor Fortran-Quellen bearbeitet, so konnte der Editor keine Unter- 
stutzung im Syntax-Bereich mehr bieten. Wichtig zu erkennen ist also hier die Integration des Wissens uber nachge- 
schaltete Werkzeuge als fester Bestandteil eines vorgeschalteten Werkzeugs beim Stand der Technik. 
[0009] Fur Werkzeuge, welche die hoherwertige Semantik eines Software-Systems zu modellieren gestatten, sind 
solche antizipativen Fehlererkennungshilfen nicht verfugbar. Beispiele fur solche Werkzeugtypen sind Analysewerk- 
zeuge etwa zur Erfassung von Klassenkarten - die sog. CflC^Technik— Class, Responsibility, Collaboration - oder 
zur Beschreibung von Designs in Modellierungssprachen wie der UML— Unified Modeling Language (siehe auch 
James Rumbaugh, Ivar Jacobson, Grady Booch, The Unified Modeling Language Reference Manual, Addison Wesley 
Longman, Reading MA, 1999). 

[0010] Erwahnenswert ist auch der Bereich der Emulation oder Simulation: Hier ahmen Softwaresysteme das Ver- 
halten anderer Systeme nach. Zum Beispiel gibt es Software-Emulatoren fur Mikroprozessoren. Der IMachteil emula- 
tiver Systeme ist, dal3 sle im Gegensatz zu elnem Model! der FShigkeiten eines Werkzeugs oder einer Komponente 
in der Regel keinerlei Verkurzungsaspektgemaft der Modelltheorie aufweisen, also die Durchf uhrung bestimmter Uber- 
priifungen in keiner Weise vereinfachen. Anders gesagt ergibt sich durch Emulation in dem hier betrachteten Zusam- 
menhang kein Vorteilgegenuberdertatsachlichen Umschaltung in das betreff ende Werkzeug, da nur das ganze Werk- 
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zeug selbst "dupliziert" wird, nicht jedoch seine fur die Fehleranalyse entscheidenden Regeln und Bedingungen. 
[0011 J Ein weiterer Bereich, in dem Eigenschaften von Systemen, Werkzeugen und Komponenten bereits fruh in 
einem EntwurfsprozeB eine Rolle spielen, 1st die Architektur, hier besonders der Bereich Hochbau. Dabei gehen die 
Eigenschaften etwa von Baumaterialien bereits in die Planungsphase ein. So beeinf luBt beispielsweise die Tragfahig- 

5 keit von Stahlbeton den Entwurf der Decken.in einem Hochhaus. Im Architekturbereich ist jedoch eine Formalisierung 
dieses Prozesses nicht gegeben. Das Problem wird hier durch vermehrte Kommunikation zwischen den beteiligten 
Personen gelost. Beispielsweise werden in den PlanungsprozeB neben dem Architekten auch Bauingenieure oder 
Statiker mit einbezogen, die dann den Architekten beim Entwurf unterstiitzen und von ihm geplante Konstruktionen 
, auf Machbarkeit uberprufen. 

10 [0012] Es ist eine zentrale Erkenntnis, nicht nur im Bereich der Informationstechnologie, daB die fruhzeitige Erken- 
nung und Behebung von Fehlern erheblich zur wirtschaftiichen Durchfiihrung von Entwicklungsprojekten beitragt. Mit 
wenigen Ausnahmen, z.B. vorgenannte Quellcode-Editoren, existiert jedoch eineantizipative Fehlererkennung entlang 
einer Werkzeugkette im Bereich des Softwareentwurfs bisher nicht. Dadurch werden viele Fehler erst spat in der Kette 
entdeckt, und es vergroBert sich somit die Anzahl an Durchlaufen durch den Entwicklungszyklus zur Behebung dieser 

15 Fehler. Das ist aufwendig und kostet viel Zeit und Geld. 

[0013] Ein ursachliches Problem ist dabei die Sicht eines jeden Werkzeugs entiang einer Kette, die eingeschrankt 
ist auf die von ihm bearbeiteten Aspekte des Gesamtsystems. Eine ganzheitliche Sicht fehlt. 
[0014] Auch sind die wenigen vorhandenen Mittel, wie etwa Syntaxhervorhebung in Quellcodeedltoren, nur mit ge- 
ringem semantischen Wissen uber die tatsachlich zu prufenden Bedingungen ausgestattet. Zum Beispiel konnen die 

20 meisten Quellcodeedltoren zwar Schlusselwdrter der Zielsprache erkennen und entsprechend hervorheben; die Uber- 
prufung, ob die Verwendung des Schlusselwortes an diese Stelle zulassig ist, unterbleibt jedoch in aller Regel. 
[001 5] Etwas weiter geht hier der Ansatz, den Werkzeuge im Bereich der Softwareentwickiung mit der Programmier- 
sprache Smalltalk verfolgen. Dort sind der Quellcodeeditor und die syntaktische und semantische Analyse des Codes 
eng miteinander verwoben. Man konnte soweit gehen und von einem integrierten Werkzeug sprechen. Dadurch wird 

25 zwar auf der einen Seite eine rasche und elnfache Prufung des Quelltextes moglich, auf der anderen Seite ist die 
Anpassung der zu prufenden Regeln und damit die Verwendung des Editors mit einer anderen Programmiersprache 
nicht mehr moglich. 

[001 6] Ein weiterer entscheidender Punkt ist, daB durch die Vielzahl verfugbarer Werkzeuge und Komponenten die 
daraus ableitbare Anzahl von verschiedenen moglichen und sinnvollen Werkzeugketten sehr gro3 ist. So konnte bei- 
30 spielsweise ein DesignWerkzeug prinzipiell zwar erkennen, daB ein bestimmtes Design nicht auf das gewahlte Daten- 
bankprodukt abbildbar ist, aber dazu fehlt es bis jetzt den Designwerkzeugen an offenen Schnittstellen, uber die eine 
Beschreibung der Regeln nachfolgender Werkzeuge und Komponenten so erfolgen kann, daB sie vom Designwerk- 
zeug uberpruft werden konnten. 

[0017] Daraus ergeben sich nachfolgend Probleme, soil einmal ein Werkzeug oder eine Komponente in der Kette 
35 ausgetauscht werden. Im schlimmsten Fall treten bestimmte Fehler erst in einem ausgelieferten System auf { weil sie 
zuvor unentdeckt biieben. Wahrehd man heute diesen Problemen durch massiven Testaufwand im Vorfeld einer Aus- 
lieferung begegnet, konnen durch verbesserte Werkzeugunterstutzung bei der Fruherkennung von Fehlern diese Auf- 
wande erheblich reduziert werden. 

[0018] Der Erfindung liegt die Aufgabe zugrunde, ein System anzugeben, das es ermoglicht, entlang einer Werk- 
'40 zeugkettefruhzeitig im EntwurfsprozeB Fehler in dem im Entwurf befindlichen Software-Anwendungsmodell zu erken- 
nen, und zwar ubergreifend uber die Aspekte aller beteiligten Werkzeuge und Komponenten entlang der Kette. 
[0019] Diese Aufgabe wird gelost durch ein System zur Verifikation von Software-Anwendungsmodellen in Ketten 
von Software-Entwurfswerkzeugen mit den im Anspruch 1 angegebenen Merkmalen. Vorteilhafte Ausgestaltungen 
sind in weiteren Anspruchen angegeben und der hachstehenden Beschreibung von Ausfuhrungsbeispielen zu ent- 
45 nehmen. 

[0020] Bei der Erfindung handelt es sich urn ein System, das es ermoglicht, Bedingungen und Regeln fur ein Soft- 
ware-Anwendungsmodell so zu formulieren, daB sie anschlieBend auf ein bestehendes Sdftware-Anwendungsmodell 
angewendet und das Modell somit auf Vertraglichkeit mit diesen Bedingungen und Regeln uberpruft werden kann. Die 
Regeln/Bedingungen konnen dabei zu Gruppen zusammengefaBt werden. die beispielsweise jeweils aus der Sicht 
so eines einzelnen Werkzeugs oder einer einzelnen Komponente formuliert sind. Die Anwendung und OberpKifung der 
Regeln kann jedoch unabhangig von einem bestimmten Werkzeug zu beliebiger Zeit an beliebiger Stelle in der Werk- 
zeugkette stattfinden. Die Gesamtmenge der jeweils gultigen Regeln/Bedingungen ergibt sich dann aus der Kombi- 
nation derjenigen Regelgruppen zu den Werkzeugen und Komponenten, die in der verwendeten Werkzeugkette ar- 
rangiert wurden. 

55 [0021] Die Beschreibung der Regeln erfolgt unter Verwendung.derSchnittstelle des Modells, welche durch ein Me- 
tamodell definiert wird. Neben dem Modell kann eine Regel auf eine vom Software-Anwendungsmodell unabhangige 
Parametermenge zugreifen, welche beispielsweise die Fahigkeiten einer eingesetzten Softwarekomponente be- 
schreibt und somit Anforderungen an das Modell beschreibt und / oder parametriert. 
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[0022J Das System laBt sich in folgende Teile untergliedern, die im AnschluB detailliert eriautert werden: 
[0023J Grundlage ist das Metamodell, welches die Struktur von und Schnittstellen zu Modellen von Software-Syste- 
men beschreibt und auf dem alle Wertaeuge in einer Kette aufbauen. Die Regeln und die diese uberprufenden Algo- 
rithmen sind in einemsogenannten Verifier Framew)riczusammengefugt. Regeln konnen flexibel parametriertweriien, 
s wobei ein spezielles Verfahren die Wiederverwendung von Parametengruppen erlaubt. Zuletzt wird noch die Integration 
der Regelprufung in eine Werkzeugkette beschrieben. 

Metamodell 

10 [0024] Als Grundlage des hier verwendeten Metamodells fur die Beschreibung von Modellen von Software-Systemen 
wird hier der UML-Standard eingesetzt. Damit sind die Basiselemente eines objektorientierten Software- Systems be- 
schreibbar, beispielsweise Classifier, Namespace, Operation, Parameter oder Generalization. Die Erfindung ist jedoch 
auch auf Erweiterungen eines solchen Standard-Metamodells, z.B. UML profiles, oder auf beliebige andere Meta- 
modelle anwendbar, z.B. wenn das Modell zusatzlich Zusammenhange zwischen Teilen einer Komponente zu be- 

15 schreiben erlaubt, wie dies der CCM - CORBA Components Standard vorsieht oder wenn Quellcodeelemente als Teile 
des Modells beschrieben werden. 

[0025] Es muB eine definierte Schnittstelle geben, uber die auf Instanzen des Metamodells, also auf Modelle von 
Software-Systemen, zumindest lesend zugegriffen werden kann, Dabei mussen uber diese Schnittstelle die Eigen- 
schaften der im Modell beschriebenen Elemente und deren Beziehungen untereinander abfragbar sein. 

20 

Verifier Framework, Anwendung von Verifiern auf Modellelemente 

[0026] Wie bereits oben erwahnt werden Regeln zu Gruppen zusammengefaBt. Diese Gruppen werden mit dem 
Begriff l/fer/fierbezeichnet. Das Verifier Framework regelt nun das Zusammenspiel der einzelnen Verifiers und deren 
25 Ausfuhrung / Oberprufung gegen ein bestehendes Modell. 

[0027] Grundidee des Frameworks ist es, eine Menge von Verifiern auf eine Menge von Modellelementen anzuwen- 
den und dabei alle gefundenen Regelverletzungen aufzuzeichnen. Zu diesem Zweck muB das Framework folgende 
Fahigkeiten bieten: 

30 • Zusammenstellung einer Menge anzuwendender Verifier 

• Festlegung der Menge von Modellelementen, auf die die Menge von Verifiern anzuwenden ist 

• Ausfuhrung der Verifier auf alien zuvor festgelegten Modellelementen bei gleichzeitiger Protokollierung aller f est- 
3s . gestellten Regelverletzungen 

• menschen- und maschinenlesbare Presentation der gefundenen Verietzungen sowie konstruktive Fehlerbehe- 
bungshilfen 

40 [0028] Die Zusammenstellung der anzuwendenden Verifier erf olgt durch eine elgens daf ur vorgesehene Komponen- 
te, den Verifier Manager. Uber diese konnen dem Framework Verifier bekanntgegeben werden. Einzelne Verifier kon- 
nen damit dynamisch zu einem Uberprufungslauf hinzugenommen oder abgeschaltet werden. Dies kann dabei ent- 
weder programmatisch durch eine Anwendung geschehen , die sich der Funktionalitat des Verifier Frameworks bedient, 
oder durch eine eigene interaktive Benutzungsschnittstelle des Frameworks. 

45 [0029] Die Auswahl der Modellelemente, auf die die festgelegten Verifier anzuwenden sind, erfolgt durch explizite 
Auflistung. Zusatzlich kann fursolche Modellelemente, die weitere Modellelemente enthalten, z.B. ein Package, fest- 
gelegt werden, ob die Regeln bei einem Durchlauf auch transitiv auf die enthaltenen Elemente angewendet werden 
sollen. Urn also beispielsweise das gesamte Modell auf RegelverstoBe zu uberortifen, mussen lediglich die Package- 
Modellelemente. die sich nicht in weiteren Pac/rage-Strukturen geschachtelt befinden, ausgewah It werden, und die 

50 Regeln mussen transitiv auf alle enthaltenen Modellelemente angewendet werden. Dadurch wird dann das gesamte 
Modell erfaBt. 

[0030] Bei der Ausfuhrung der Verifier gegen die Modellelemente nutzt das Framework die Tatsache aus, da3 jeder 
Verifier eine- jeweils die gleiche - Schnittstelle zur Ubergabe eines Modellelements zur Uberpnjfung durch diesen 
Verifier unterstutzen muB. Somit kann das Framework homogen und durch Ausnutzung der objektorientierten Technik 
55 der Polymorphie\efem registrierten und ausgewShlten Verifierjedes zur Uberprtifung anstehende Modellelement uber 
diese Schnittstelle zur Prufung vorlegen. Das Ergebnis einer jeden solchen Prufung ist eine Liste gefundener Regel- 
verletzungen, die jeweils genugend Information enthalten mussen, urn daraus eine informative Meldung fur den An- 
. wender abzuleiten, so daB fur diesen der gefundene VerstoB eindeutig identifizierbar und somit behebbar wird. Entlang 
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. der Ausfuhrung aller selektierten Verifier auf alle festgelegten Modellelemente werden diese Regelverletzungslisten 
gesammelt und zusammengefugt, so daB am Ende eine einzige Gesamtliste entsteht, die dem Anwender prasentiert 
werden kann. 

[0031 ] Es ist hierbei wichtig zu erwahnen, daB eine Regel auch spezifisch fur bestimmte Arten von Modellelementen 
5 sein kann. Es ist die Aufgabe des Verifiers, zu bestimmen, welche seiner enthaltenen Regeln er tatsachlich auf ein an 
ihn zur Uberprufung ubergebenes Modellelement anwendet. 

[0032] Bei der Prasentation der Regelverietzungen werden folgende Aspekte einer Verletzung berucksichtigt: Die 
Schwere der Verletzung, also z.B. "Warnung" oder "Fehler", Auswirkungen des Fehlers Oder der Warnung, z.B. Per- 
formance-EinbuBen, ein informativer Text im Sinne einer Fehlermeldung, konstruktive Hinweise zur Behebung des 
10 Fehlers und eine Uste beteiligter Modellelemente, aus der fur den Anwender ablesbar ist, an welcher Stelle im Modell 
genau die Verletzung vorliegt und mitunter wie sie zustandekommt. Wenn das Werkzeug, in das die Pruf ung integriert 
ist, die Kenntlichmachung von Modellelementen unterstutzt, kann diese Eigenschaft ausgenutzt werden, urn die be- 
teilgten Modellelemente he rvorzuheben. Diese Attribute der gefundenen Regelverietzungen lessen sich elegant in 
einer graphischen Prasentation zusammenfugen. 

15 

■ Flexible Parametrierung von Verifiem und die Uberladungssemantik bei der Beschreibung dieser Regeln in Sequenzen 
von XML-Dateien 

[0033] Das bisher Gesagte Ial3t weitestgehend often, wie die Regeln und die durch sie ausgedruckten Anspruche 
20 an das Modell formuliert werden. Soweit wurde nur gefordert, daB das Metamodell die Schnittstelle vorgibt, uber die 
die Regeln auf das zu prufende Modell des Software-Systems zugreifen konnen. Es gibt jedoch Randbedingungen, 
die weitergehende Uberlegungen rechtf ertigen: 

[0034] Oftmals erfullen Komponenten und Werkzeuge entlang einer Werkzeugkette bestimmte Standardaufgaben, 
fur deren Erledigung nicht ausschlieBlich das spezielle, ausgewahlte Werkzeug in Frage kommt. Andere Werkzeuge 
25 und Komponenten mSgen weitestgehend die gleichen Anforderungen erfullen, moglicherweise jedoch jeweils mit ge- 
wissen Abweichungen und Unterschieden. Daraus lassen sich entsprechend unterschiedliche Verifier ableiten, die 
zum einen Standardregeln, zum anderen spezielle Regeln fur die Abweichungen des gewahlten Werkzeugs bzw. der 
gewahlten Komponente ausdriicken mussen. 

[0035] Dieser Anforderung tragt der bisher beschriebene Teil des Verifier Frameworks nur bedingt Rechnung. Die 
30 Standardregeln konnten in separaten Verfiern ausgedruckt werden, die Regeln zu den Abweichungen in wieder an- 
deren Verifiers Der Verifier fur ein Werkzeug bzw. eine Komponente ergibt sich dann durch Zusammenfugen der 
Verfier fur die Standardregeln mit den Verifiern fur die Abweichungen. 

[0036] Oft sind die Unterschiede jedoch so beschaffen, daB ein eigener Verifier nicht gerechtfertigt erscheint und 
stattdessen die Parametrierung von Regeln angemessener ist. In solchen Fallen kommen parametrierbare Verifier 

35 zum Einsatz. Entscheidend dabei ist, daB Parametersatze fur Standardregeln festlegbar sind, die dann im Fade von 
Abweichungen gezielt abgeandert und erweitert werden konnen, ohne dabei die Parameterfestlegungen fur die Stan- 
dardregeln selbst modifizieren oder kopieren zu mussen. Nur so ist gewahrleistet, daB verschiedene Parametersatze 
gleichzeitig aus den Standardsatzen ableitbarsmd, Anderungen an den Standardparametern sich auf alle abgeleiteten 
Satze auswirken, die diese Anderungen nicht bereits speziell umdefinieren und daB die Standardparameter fur weitere 

*o Ableitungen wlederverwendbar bleiben. 

[0037] Dieses Prjnzip lehnt sich an dieTechnik der Vererbung 'm objektorientierten Software-Systemen an, wo Klas- 
sen Eigenschaften definieren konnen, die dann von abgeleiteten Klassen uberladen werden konnen. Auch dort sind 
die Ziele die Wiederverwendung der Oberklasse, die automatische Propagierung von Anderungen und Erweiterungen 
der Oberklasse auf bestehende Unterklassen und die Moglichkeit der f lexiblen Anpassungen der Unterklassen auf die 

45 geanderten Anforderungen der Spezialisierung, die sie gegenuber der Oberklasse darstellen. 
[0038] Es ergeben sich folgende Merkmale fur die Formulierung von Parametern: 

• Parameter werden zu Pa/ame/ersatzerJ zusammengefaBt 

50 • Parameter sind innerhalb eines Namensraumes eindeutig identifizierbar 

• Es kann eine Sequenz mehrerer Parametersatze in einem Namensraum vereinigt werden, wobei durch die Rei- 
henfolge eine Uberladungssemantik fur Parameter gleichen Namens im Kontext dieses Namensraumes def iniert 
wird. 

55 

Formalisierung der Uberladungssemantik: 

[0039] Sei s := {s p sj eine Sequenz von Parametersatzen mit s, ;= ((n w p it ), ... , (n^p^ }. Der Satz mit der 
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Ordnungsnummer /besteht also aus einer Menge von m(i) Paaren, deren erstes Element den Namen des Parameters 
im Namensraum und deren zweites Element den Parameterwert angibt. Dann ergibt sich der Wert p des Parameters 
mlt dem Namen n Im Kontext der Sequenz von Parametersdtzen s mlt obiger Deflnintion wle folgt: 

5 




p 0 falls n~ = n aVi < k <r :Vl£/ <m(k):n u *n 
undefiniertsonst 



to Implementlerung mit Sequenzen von XML-Dateien 

[0040] Eine Implementierung dieser Semantik kann z.B. so erfolgen, daf3 s abgebildet wird auf elne Sequenz von 
XML-Dateien (d 1t ... , dj. Fur eine Beschreibung des XML-Standards siehe auch Brett McLaughlin, Mike Loukides, 
Java.andXML first edition, O'Reilly & Associates, June 2000, ISBN 05960001 62. Der Namensraum ist bestimmt durch 

15 die Ausdrucksmoglichkeiten von XML, das im wesentlichen zwischen sogenannten Elementen und Attributen unter- 
scheidet. Element- und Attributstnjktur konnen vorgegeben werden durch die fur d v d r einheitliche OTO— Docu- 
ment Type Definition. Dabei sind Elemente benannt und konnen geschachtelt werden; jedes Element kann eine Menge 
von benannten Attributen aufweisen, diejeweils einen Wert zugewiesen haben konnen. Weiterhin konnen Elemente 
beliebigen Text in einem Textkorper enthalten, der jedoch hier nicht weiter betrachtet werden soli. 

20 [0041] Der Name laSt sich somit eindeutig als ein Elementpfad, also, ein Pfad im Gegensatz zu einem einfachen 
Namen aufgrund der potentiellen Schachtelung der Elemente, und abschlieBend den Namen des Attributs des letzten 
Elements in diesem Pfad forrnulieren. Der Parameterwert ist definiert als der Wert des ausgewahlten Attributes. Er 
kann somit alle Werte annehmen, die ein XML-Attribut annehmen kann. 

[0042] Eine XML-Datei d,beschreibt also einen Parametersatz s h Ein Name n wird realisiert als Pfad, der die Namen 
25 vongeschachtelten Elementen inderSchachtelungsreihenfolgeundamEndeden Namen eines Attributs des Innersten 
Elements enthalt. Der Wert des Attributs in der XML-Datei stellt den Wert des Parameters innerhalb des Satzes s, dar. 
Die Uberladungssemantik kann dann wie oben formalisiert angewendet werden. 

Veranschaulichung, Vorzuge: 

30 

[0043] Bildlich gesprochen ergibt sich durch dieses Verfahren ein "Stapel" von Dateien, die erste Datei d 1 der Liste 
zuunterst, die letzte rf r zuoberst, wobei gleichnamige Parameter ubereinanderliegen; "undurchsichtig" sind und somit 
"weiter unten" iiegende Parameterwerte uberdecken, wohingegen Parameter nach oben "durchscheinen", wenn dar- 
uberliegende Dateien sie nicht uberladen. Siehe dazu die Abbildungsfiguren Fig. 3 bis Fig. 7. 
35 [0044] In dieser Anordnung reprasentieren die weiter unten liegenden Dateien die Standards, die.dann von spezi- 
elleren Parametern fur die Abweichungen angepaBt werden konnen. 

[0045] Mit dieser Implementierung sind Parametersatze z.B. mit einem einfachen Texteditor bearbeitbar; eine Ober- 
setzung als ein separater Schritt zur Nutzbarmachung dieser lnformationen : wie dies etwa bei Implementierung eines 
Parametersatzes als Java-Programm anfallen wurde, entfallt. 
to [0046] Ein parametrierbarer Verifier hat nun neben dem Zugriff auf das Modell des Softwaresystems zusStzlich die 
Menge definierter Parameter zur Verfugung, die sich aus der Zusammenstellung der beschriebenen Sequenz von 
XML-Dateien ergibt und kann deren Werte in die Auswertung der Regeln mit einbeziehen. 

Integration des Verifier Frameworks in Werkzeugketten 

45 

. [0047] Die Art und Weise, auf die die Regelpriifung in die Werkzeugkette integriert wird, hangt stark von der Be- 
schaffenheit der Kette selbst ab, unter anderem von der Semantik der elnzelnen Schritte und der Erwelterbarkelt der 
verwendeten Werkzeuge. Elegant, aber nicht zwingend notwendig, ist naturlich die Integration in ein bestehendes 
Werkzeug hinein, so da(3 die Regelprufung noch im Werkzeug selbst erfolgen kann und somit die Zeit und der Aufwand . 
50 fur das Hin- und Herschalten zwischen Werkzeug(en) und Regelprufung entfallt. 

[0046] Bieten die Werkzeuge diese Funktionalitat jedoch nicht, so kann dennoch eine Regelprufung durch Ausfuh- 
rung als separates Werkzeug erfolgen, welches dann an einer oder mehreren Stellen in die Werkzeugkette integiert 
wird. * 
[0049] Eine weitere Eriauterung der Erfindung erfolgt anhand von Zeichnungsfiguren. Es zetgen: 

55 

Fig. 1 : Ubersicht Verifier Framework am Beispiel UML/Java/J2EE, 
Fig. 2: Fehlerhaftes Modell, 

Fig. 3: Veranschaulichung der Uberladungssemantik von Parametersatze^ 
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Fig. 4: Standardparameter fur einen parametrierbaren Verifier, 
Fig. 5: Erste Uberiadung von Parametern fur eineri parametrierbaren Verifier, 
Fig. 6: Zwelte Uberiagung von Parameters fOr einen parametrierbaren Verifier und 
Fig. 7: Ergebnis der angewendeten Uberladungssemantik. 

5 

[0050] Die Diagramme in diesem Abschnitt orientieren sich an der UML-Notation. 

[0051 ] Fig. 1 zeigt den Verifier Manager, seine Beziehung zu den Verifiern und die Struktur der verschiedenen Verifier. 
Der Manager kennt eine beliebige Anzahl von Verifiern. Dabei ist tferifferselbst nur eine Schnittstellenbeschreibung, 
wie am Stereotyp interface* zu erkennen ist, welche die Methodenschnittstelle zum Anwenden des Verifiers auf ein 

10 Modellelementdefiniert. im Bildsindverschiedene Verifier- Varianten gezelgt, unteranderem ein Verifier, derdas Modell 
auf UMl-Regeln prufen soil, im Beispiel der UMLVerifier, einer, der es auf Regeln der Sprache Java Oberpriifen soil 
und ein parametrierbarer Verifier, der die J2EE-spezifischen Regeln prufen soli. Eine Beschreibung des J2EE-Stan- 
dards findet sich beispielsweise in Paul Perrone, Venkata S.R.K.R. Chaganti, Building Java Enterprise Systems with 
J2EE, Sams; June 2000, ISBN: 0672317958. Im Bild ist die wichtige Beziehung zwischen den Verifier-lmpiementie- 

15 rungen und der Ver///er-Schnittstelle festgehalten: Die konkreten Verifier implementieren die Verif ier-Schnittstelle, kon- 
nen somit dem Verifier Manager bekanntgegeben werden, und dieser kann sie polymorph verwenden, urn Modellele- 
mente durch sie prufen zu lassen. 

[0052] Fig. 2 zeigt ein beispielhaftes Modell. An ihm soli die Anwendung einer Menge von Verifiern auf eine Menge 
von Modeilelementen erlautert werden. Es sei das Verifier- Mo del I aus Fig. 1 zugrunde gelegt. Auf das in Fig. 2 gezeigte 

20 Package Psoll also die folgende Liste von Verifiern angewendet werden, und zwar auch auf seine enthaltenen Ele- 
mente: <UML Verifier, Java Venfier>. Dabei prufe der UML Verifier die Regel, da3 ein interface nie ein Nicht-lnterface 
spezialisieren kann. Der Java Verifier prufe die Bedingung, daG kein Classifier mehr als ein Attribut mit demselben 
Namen enthalt. Nun wird zuerst der UMLVerifier Package P angewendet. Fur ein Package wendet der Verifier im 
Beispiel keine Regel an. AnschlieBend, da auch alle enthaltenen Modellelemente des Packages zu verifizieren sind, 

25 wird dem Verifier der Reihe nach Modellelement A, dann B und dann C ubergeben. W§ hrend bei A und C keine Regel 
des UML Ifer/tfers verletzt ist, entdeckt erbei B, dalB hier ein Interface, namlich B, ein Nicht-lnterface, hier Aspezialisiert. 
Damit ist eine Regel verletzt, und es wird eine entsprechende Fehlermeldung mit den Classifiern A und B als beteiligten 
Modeilelementen zusammen mit einer beschreibenden Fehlermeldung in die Ergebnisliste eingefugt. 
[0053] Der JavaVerifier bekommX auf die gleiche Weise die Classifier A, B und C ubergeben und stellt bei A die 

30 Verwendung zweier Attribute mit dem gleichen Namen fest. Damit ist eine seiner Regeln verletzt und es wird wieder 
ein Fehlerprotokoli an die Ergebnisliste angehangt. 

[0054] Fig. 3 zeigt die Uberlagerung mehrerer XML-Dateien zur Definition von Parameterwerten, auf die ein para- 
metrierbarer Verifier zugreifen kann. Im Beispiel sind drei Dateien dargestellt: eine zur Beschreibung von Standard- 
parametern, eine zur Uberlagerung und Erweiterung der Standardparameter mit speziellen Werten fur ein Produkt X, 

35 und eine dritte fur zusatzliche Erweiterungen und Umdefinitionen fur ein weiteres Produkt Y. Die Grafik soli verdeutli- 
chen, da3 in dieser Anordnung "welter oben" liegende Parameterwerte solche, die "weiter unten" liegen, verdecken. 
[0055] Die Abbildungsf iguren Fig. 4 bis Fig. 7 zeigen ein Beispiel fur die Uberlagerung mehrerer Parameterdateien. 
Fig. 4 zeigt die Menge der Standardparameter. Fig. 5 zeigt die Parameter fur Werkzeug / Komponente X und Fig. 6 
zeigt diejenigen fur Werkzeug / Komponente V. Fig. 7 schlieBlich zeigt das Ergebnis der Uberlagerung in der Reihen- 

*o folge <Standard, X, Y>. 

[0056] Das ganze sei nochmals am Beispiel aus Fig. 2 demonstriert. Gegeben seien die folgenden XML-Parameter- 
dateien defauft.cap, associations.cap und ejbContainerX.cap mit den folgenden auszugsweisen Inhalten: 

default.cap: 

45 
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Associations 

Interf aceFromlnterf ace=" supported 1 ' 
Interf aceFromClass=" supported" 
Clas sFromClass=" supported" 

i> 

• • • 

associations. cap: 

Associations 

c01-01=" supported" 
c01-0n="not_supported" 
c0n-0n=" nonsupported" 

/> 



ejbContainerX.cap: 



<associations 

cO 1 - 0n= " supported" 

/> 



[0057] Der J2EEVerifier priife die Multiplizitaten der im Modell auftretenden Assoziationen zwischen Classifiern und 
die Stereotypen der Classifier an den Assozlationsenden, also z.B. ob eine Bezlehung zwischen Interface und Class 
zulasslg ist, Oder ob eine Beziehung zwischen zwei Interfaces erlaubt sein soil. Die Menge der erlaubten Multiplizitaten 
werde dabei aus den angegeben XML-Parameterbeschreibungsdateien gewonnen, und zwar im ersten Durchlauf mit 
der Dateiliste <defauttcap, association$.cap>. Bekommt der Verifier das Modellelement ubergeben, welches die As- ' 
soziation aus Fig. 2 zwischen C und B pruft, dann werden folgende Parameter angefordert: associations: interfaceF- 
romClass, da es sich urn eine Assoziation von einem Classifier ohne speziellem Stereotyp, also "Class" und einem 
Classifier mit dem Stereotyp "«interface» M handelt; und associationsicOI-On, da das eine Assoziationsende die Multi- 
plizitat "0. . 1" und das a ndere "0 . .n" aufweist. Wahrend der Verifier fur den ersten Parameter "supported* als Wert emalt, 
was die Beziehung zwischen Class und Interface fur erlaubt erklSrt, erhait er fur den zweiten Parameter den Wert 
"nonsupported 1 , wie in associations. cap def in iert. Es wird folglich ein Fehlerreport erzeugt, der die Sund Cals beteiligte 
Modellelemente nennt und auf die Verletzung der erlaubten Multiplizitaten hinweist. 

[0058] Wird nun zu der Liste der Dateien noch die Datei ejbContainerX.cap hinzugenommen, ergibt sich die Liste 
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<defauttcap, associations.cap, ejbContainerX.cap>. Wird mit dieser Liste der zuvor beschriebene Durchlauf wieder- 
holt, so meldet der Verifier diesmal keine Regelverletzurig, da die Multiplizitatenkombination O..1/0..n durch die Angabe 
in ejbContalnerX.cap als "supported' erkldrt wurde. So kann also ohne einen Eingriff in den Verifier seine Regelmenge 
einfach und unter Einhaltung der zuvor genannten Bedingungen wie etwa Wiederverwendbarkeit der Standardpara- 
meterwerte erweitert / modifiert werden. 



Patentanspruche 

1. System zur Veriflkation von Software-Anwendungsmodeilen in Ketten von Software-Entwurfswerkzeugen, wobel 

a) die Anwendungsmodelle Instanzen eines Metamodells sind, welches die Struktur von Modellen einer Soft- 
ware-Anwendurig sowie Schnittstellen zu diesen Modellen beschreibt, und auf dem alle Werkzeuge der Werk- 
zeugkette aufbauen. 

b) ein Verifier- Framework einschlieBiich einem Verifier-Manager sowie mehrere Verifizierer existieren, wobei 
ein Verifizierer jeweils als eine Gruppe von formulierten Bedingungen und Regeln fur die Modelle von Software- 
Anwendungen gebildet wird, und mittels des Verifier-Managers Verifier-Gruppen im Verifier-Framework zur 
Prufung festgelegter Modellelemente zusammengestellt werden, und 

c) das System dafur eingerichtet ist, die Verif izierung von Softwaremodellen beziiglich Vertraglichkeit mit den 
formulierten Bedingungen und Regeln mittels eines Uberprufungslaufs unter Verwendung des Metamodells 
vorzunehmen, wobei sich als Ergebnis die festgestellten Bedingungs- oder Regelverletzungen ergeben. 

2. System nach Anspruch 1 , dadurch gekennzeichnet, daB das Metamodell auf dem UML(Unified Modeling Lan- 
guage)-Standard basiert. 

3. System nach einem der vorstehenden Anspr£iche : dadurch gekennzeichnet, daB es dafur eingerichtet ist, pa- 
rametrierbare Verifier zu bilden und zu verwenden, die es ermoglichen, in der Regelformulierung neben dem An- 
wendungsmodell auch auf die Werte dieser Parameter zuzugreifen und somit die Regeln durch Parametersatze 
anzupassen, ohne die Regeln selbst andem zu mussen. 

4. System nach einem der vorstehenden Anspruche, dadurch gekennzeichnet, daB der Verifier- Manager defur 
eingerichtet ist,einzelne Verifier dynamisch zu einem Oberprufungslauf hinzuzunehmen oder abzuschalten. 

5. System nach Anspruch 4, dadurch gekennzeichnet, daB der Verifier-Manager dafur eingerichtet ist, die dyna- 
mische Zu- oder Abschaltung von Verifiem programmatisch durchzufuhren, oder es zu ermoglichen, daB sie durch 
ein Anwenderprogramm erfolgt, das sich derFunktionalitat des Verifier- Framworks bedient, oder durch eineeigene 
interaktive Benutzungsschnittstelle des Verifier- Framworks. 

6. System nach einem der Anspriiche 3, 4 oder 5, dadurch gekennzeichnet, daB es dafur eingerichtet ist, Parame- 
tersatze fur parametrierbare Verifier aus Sequenzen von Parametersatzen zusammenzusetzen, bei denen entlang 
der Sequenz Parameterwerte uberladen werden. 

7. System nach Anspruch 6, gekennzeichnet dadurch, daB die Parametersatze fiir paramerierbare Verifier in Text- 
dateien im ASCII-Format abgelegt sind. 

8. System nach Anspruch 7, dadurch gekennzeichnet, daB als innere Struktur der Textdateien das XML-Format 
verwendet ist. 

9. System nach einem der vorstehenden Anspruche, dadurch gekennzeichnet, daB das System in der Program- 
miersprache Java erstellt ist. 
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Fig. f; Obersicht Verifier Framework am Beispiel UML/Java/J2EE 
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Package P 



number:String 
number:int 



7T 



"0..1 0..n 



«interface» B 



verifyModelElement() 



Fig. 2: Fehlerhaftes Model! 
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Fig. 3: Veranschaulichung der Uberladungssemantik von Parametersatzen 
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Fig. 4: Standardparameter fur einen parametrierbaren Verifier 
Parameter EJB Produkt X 
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Fig. 5: Erste Uberiadung von Parametern fur einen parametrierbaren Verifier 
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\\\\\\\ Attribut uberschrieben von Standard 
/////// Attribut uberschrieben von X 
Attribut hinzugefugt 



Fig. 6: Zweite Uberladung von Parameters fiireinen parametrierbaren Verifier 
Parameter der Liste <Standard, X, Y> 
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Fig. 7: Ergebnis der angewendeten Uberladungssemantik 
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